home *** CD-ROM | disk | FTP | other *** search
/ CD Exchange / CD Exchange - Volume 1.iso / graphics / utils / viewtek / anim7.doc next >
Text File  |  1992-12-06  |  29KB  |  602 lines
  1.  
  2.  
  3.                               A N I M
  4.                   An IFF Format For CEL Animations
  5.  
  6.                     Revision date:  4 May 1988
  7.  
  8.                      prepared by:
  9.                           SPARTA Inc.
  10.                           23041 de la Carlota
  11.                           Laguna Hills, Calif 92653
  12.                           (714) 768-8161
  13.                           contact: Gary Bonham
  14.  
  15.                      also by:
  16.                           Aegis Development Co.
  17.                           2115 Pico Blvd.
  18.                           Santa Monica, Calif 90405
  19.                           213) 392-9972
  20.  
  21.              Anim7 Appendix (july 92) by:
  22.               Wolfgang Hofer
  23.               A-2722 Winzendorf
  24.               Wr. Neustaedterstr. 140
  25.  
  26. 1.0 Introduction
  27.  
  28.    The ANIM IFF format was developed at Sparta originally for the
  29.    production of animated video sequences on the Amiga computer.  The
  30.    intent was to be able to store, and play back, sequences of frames
  31.    and to minimize both the storage space on disk (through compression)
  32.    and playback time (through efficient de-compression algorithms).
  33.    It was desired to maintain maximum compatibility with existing
  34.    IFF formats and to be able to display the initial frame as a normal
  35.    still IFF picture.
  36.  
  37.    Several compression schemes have been introduced in the ANIM format.
  38.    Most of these are strictly of historical interest as the only one
  39.    currently being placed in new code is the vertical run length
  40.    encoded byte encoding developed by Jim Kent.
  41.  
  42.    1.1 ANIM Format Overview
  43.  
  44.       The general philosophy of ANIMs is to present the initial frame
  45.       as a normal, run-length-encoded, IFF picture.  Subsequent
  46.       frames are then described by listing only their differences
  47.       from a previous frame.  Normally, the "previous" frame is two
  48.       frames back as that is the frame remaining in the hidden
  49.       screen buffer when double-buffering is used.  To better
  50.       understand this, suppose one has two screens, called A and B,
  51.       and the ability to instantly switch the display from one to
  52.       the other.  The normal playback mode is to load the initial
  53.       frame into A and duplicate it into B.  Then frame A is displayed
  54.       on the screen.  Then the differences for frame 2 are used to
  55.       alter screen B and it is displayed.  Then the differences for
  56.       frame 3 are used to alter screen A and it is displayed, and so
  57.       on.  Note that frame 2 is stored as differences from frame 1,
  58.       but all other frames are stored as differences from two frames
  59.       back.
  60.  
  61.       ANIM is an IFF FORM and its basic format is as follows (this
  62.       assumes the reader has a basic understanding of IFF format
  63.       files):
  64.                       FORM ANIM
  65.                       . FORM ILBM         first frame
  66.                       . . BMHD                normal type IFF data
  67.                       . . ANHD                optional animation header
  68.                                               chunk for timing of 1st frame.
  69.                       . . CMAP
  70.                       . . BODY
  71.                       . FORM ILBM         frame 2
  72.                       . . ANHD                animation header chunk
  73.                       . . DLTA                delta mode data
  74.                       . FORM ILBM         frame 3
  75.                       . . ANHD
  76.                       . . DLTA
  77.                            ...
  78.  
  79.       The initial FORM ILBM can contain all the normal ILBM chunks,
  80.       such as CRNG, etc.  The BODY will normally be a standard
  81.       run-length-encoded data chunk (but may be any other legal
  82.       compression mode as indicated by the BMHD).  If desired, an ANHD
  83.       chunk can appear here to provide timing data for the first
  84.       frame.  If it is here, the operation field should be =0.
  85.  
  86.       The subsequent FORMs ILBM contain an ANHD, instead of a BMHD,
  87.       which duplicates some of BMHD and has additional parameters
  88.       pertaining to the animation frame.  The DLTA chunk contains
  89.       the data for the delta compression modes.  If
  90.       the older XOR compression mode is used, then a BODY chunk
  91.       will be here.  In addition, other chunks may be placed in each
  92.       of these as deemed necessary (and as code is placed in player
  93.       programs to utilize them).  A good example would be CMAP chunks
  94.       to alter the color palette.  A basic assumption in ANIMs is
  95.       that the size of the bitmap, and the display mode (e.g. HAM)
  96.       will not change through the animation.  Take care when playing
  97.       an ANIM that if a CMAP occurs with a frame, then the change must
  98.       be applied to both buffers.
  99.  
  100.       Note that the DLTA chunks are not interleaved bitmap representations,
  101.       thus the use of the ILBM form is inappropriate for these frames.
  102.       However, this inconsistency was not noted until there were a number
  103.       of commercial products either released or close to release which
  104.       generated/played this format.  Therefore, this is probably an
  105.       inconsistency which will have to stay with us.
  106.  
  107.    1.2 Recording ANIMs
  108.  
  109.       To record an ANIM will require three bitmaps - one for
  110.       creation of the next frame, and two more for a "history" of the
  111.       previous two frames for performing the compression calculations
  112.       (e.g. the delta mode calculations).
  113.  
  114.       There are five frame-to-frame compression methods currently
  115.       defined.  The first three are mainly for historical interest.
  116.       The product Aegis VideoScape 3D utilizes the third method in
  117.       version 1.0, but switched to method 5 on 2.0.  This is
  118.       the only instance known of a commercial product generating
  119.       ANIMs of any of the first three methods.  The fourth method
  120.       is a general short or long word compression scheme which has
  121.       several options including whether the compression is horizontal
  122.       or vertical, and whether or not it is XOR format.  This offers
  123.       a choice to the user for the optimization of file size and/or
  124.       playback speed.  The fifth method is the byte vertical run length
  125.       encoding as designed by Jim Kent.  Do not confuse
  126.       this with Jim's RIFF file format which is different than ANIM.
  127.       Here we utilized his compression/decompression routines within the
  128.       ANIM file structure.
  129.  
  130.       The following paragraphs give a general outline of each of the
  131.       methods of compression currently included in this spec.
  132.  
  133.       1.2.1 XOR mode
  134.  
  135.          This mode is the original and is included here for historical
  136.          interest.  In general, the delta modes are far superior.
  137.          The creation of XOR mode is quite simple.  One simply
  138.          performs an exclusive-or (XOR) between all corresponding
  139.          bytes of the new frame and two frames back.  This results
  140.          in a new bitmap with 0 bits wherever the two frames were
  141.          identical, and 1 bits where they are different.  Then this
  142.          new bitmap is saved using run-length-encoding.  A major
  143.          obstacle of this mode is in the time consumed in performing
  144.          the XOR upon reconstructing the image.
  145.  
  146.       1.2.2 Long Delta mode
  147.  
  148.          This mode stores the actual new frame long-words which are
  149.          different, along with the offset in the bitmap.  The
  150.          exact format is shown and discussed in section 2 below.
  151.          Each plane is handled separately, with no data being saved
  152.          if no changes take place in a given plane.  Strings of
  153.          2 or more long-words in a row which change can be run
  154.          together so offsets do not have to be saved for each one.
  155.  
  156.          Constructing this data chunk usually consists of having
  157.          a buffer to hold the data, and calculating the data as
  158.          one compares the new frame, long-word by long-word, with
  159.          two frames back.
  160.  
  161.       1.2.3 Short Delta mode
  162.  
  163.          This mode is identical to the Long Delta mode except that
  164.          short-words are saved instead of long-words.  In most
  165.          instances, this mode results in a smaller DLTA chunk.
  166.          The Long Delta mode is mainly of interest in improving
  167.          the playback speed when used on a 32-bit 68020 Turbo Amiga.
  168.  
  169.       1.2.4 General Delta mode
  170.  
  171.          The above two delta compre